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Abstract 

FaustLive is a standalone just-in-time Faust 
compiler. It tries to bring together the conve¬ 
nience of a standalone interpreted language with 
the efficiency of a compiled language. Based 
on libfaust , a library that provides a full in¬ 
memory compilation chain, FaustLive doesn’t 
require any external tool (compiler, linker, etc.) 
to translate Faust source code into binary ex¬ 
ecutable code. 

Thanks to this technology, FaustLive pro¬ 
vides several advanced features. For example 
it is possible, while a Faust application is run¬ 
ning, to modify its behavior on-the-fly without 
any sound interruption. It is also possible to mi¬ 
grate a running application from one machine to 
another, etc. 
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1 Introduction 

Faust [Functional Audio Stream] [6] is a func¬ 
tional, synchronous, domain-specific program¬ 
ming language specifically designed for real¬ 
time signal processing and synthesis. A unique 
feature of Faust, compared to other existing 
music languages like Max, PD, Supercollider, 
etc., is that programs are not interpreted, but 
fully compiled. Faust provides a high-level 
alternative to C/C++ to implement efficient 
sample-level DSP algorithms. 

But, if compilers have the advantage of ef¬ 
ficiency, they have their own drawbacks com¬ 
pared to interpreters. Compilers traditionally 
require a whole chain of tools to be installed 
(compiler, linker, development libraries, etc.). 
For non-programmers this task can be com¬ 
plex. The development cycle, from the edition 
of the source code to a running application, is 
much longer with a compiler than with an inter¬ 
preter. This can be a problem in creative situ¬ 


ations where quick experimentation is essential. 
Moreover, binary code is usually not compatible 
across platforms and operating systems. 

FaustLive is an attempt to bring together 
the convenience of a standalone interpreted lan¬ 
guage with the efficiency of a compiled lan¬ 
guage. Based on libfaust , a library that provides 
a full in-memory compilation chain, FaustLive 
is a standalone application that doesn’t require 
any external tool to translate Faust source code 
into binary executable code and run it. In many 
aspects FaustLive behaves like a Faust inter¬ 
preter with a very short development cycle (not 
very different, in that aspect, from modern com¬ 
piled LISP environments, or from the approach 
presented by Albert Graef with Pure in [1]). 

Moreover, FaustLive provides some advanced 
features to speedup the development cycle. For 
example, while a Faust application is running, 
it is possible to edit and recompile its Faust 
code on-the-fly, without any sound interruption. 
If the application is using JACK as driver, all 
audio connections are maintained. Another in¬ 
teresting feature is the possibility to migrate a 
running application from one machine to an¬ 
other through the network even across operat¬ 
ing systems. Applications can also be controlled 
remotely, using HTTP or OSC. 

FaustLive offers a lot of flexibility to proto¬ 
type audio applications. It can also be con¬ 
nected to Faust Web, a remote compilation ser¬ 
vice to export the application as a traditional 
binary for one of the various operating system 
and audio architecture supported by the Faust 
ecosystem. 

Since FaustLive is based on libfaust , the 
Faust compiler project will first be presented 
(see Section 2). Then FaustLive will be shortly 
described through a typical use case (see Sec¬ 
tion 3) to finally be detailed over its technical 
aspects (see Section 4). 



2 Faust Compiler 

The Faust compiler translates a Faust pro¬ 
gram into an equivalent imperative program 
(typically C, C++, Java, etc.), taking care of 
generating efficient code. The Faust package 
also includes various architecture files, provid¬ 
ing the glue between the generated code and 
the external world (audio drivers and user in¬ 
terfaces) . 


ARCHITECTURE FILE 



guages. Executable code is dynamically pro¬ 
duced using a “Just In Time” compiler from a 
specific code representation, called LLVM IR 1 . 
Clang, the “LLVM native” C/C++/Objective- 
C compiler is a front-end for LLVM Compiler. 
It can, for instance, convert a C or C++ source 
file into LLVM IR code (Figure 3). 



Figure 3: LLVM compiler structure 


Figure 1: Steps of Faust compilation chain 


The current version of the Faust compiler 
produces the resulting DSP code as a C++ 
class, to be inserted in the architecture file. The 
resulting C++ file is finally compiled with a 
regular C++ compiler to produce the final exe¬ 
cutable program or plug-in (Figure 1). 

The resulting application is structured as 
shown in Figure 2. The DSP has become an 
audio computation module. As for the archi¬ 
tecture, it turned into links to the user interface 
and the audio driver. 
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Figure 2: Faust application structure 


2.1 LLVM 

LLVM (formerly Low Level Virtual Machine) is 
a compiler infrastructure, designed for compile¬ 
time, link-time, run-time optimization of pro¬ 
grams written in arbitrary programming lan- 


Domain-specific languages like Faust can 
easily target the LLVM IR. This has been done 
by developing a special LLVM IR backend in 
the Faust compiler, [5]. 

2.2 Dynamic compilation chain 

The complete chain goes from the DSP source 
code, compiled in LLVM IR using the LLVM 
backend, to finally produce the executable code 
using the LLVM JIT. All steps are done in mem¬ 
ory. Pointers on executable functions can be 
retrieved in the resulting LLVM module, and 
their code directly called with the appropriate 
parameters. 

In the faust2 development branch, the Faust 
compiler has been packaged as an embeddable 
library called libfaust , published with an asso¬ 
ciated API, [2]. This API imitates the concept 
of oriented-object languages, like C++. The 
step of compilation, usually executed by gee, 
is accessed through the function createDSP- 
Factory. Given a Faust source code (as a file 
or a string), the compilation chain (Faust 
+ LLVM JIT) generates the “prototype” of 
the class, called llvm-dsp-factory. Then, the 
function createDSPInstance, corresponding to 
the “new className” of C++, instantiates 
a llvm-dsp. It can then be used as any ob¬ 
ject, run and be controlled through its interface. 

Embedding this technology in a program or 
a plug-in enables dynamic modifications of the 
audio computation module of a Faust applica¬ 
tion [4]. 

1 The Intermediate Representation is an intermediate 
SSA representation 









































3 Faust Live - Use Case 


FaustLive is a QT-based 2 software that per¬ 
mits to launch Faust applications from their 
source code without having to precompile them 
(Figure 4). 




BEHAVIOR MODIFICATION FROM F00 TO BAA 



Figure 5: Behavior modification 
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Figure 6: Dynamic source edition 


Figure 4: FaustLive principle 


FaustLive exploit dynamic compilation, 
associated with multiple interfacing systems 
and audio drivers to modulate the structure 
of Faust applications and simplify Faust 
prototyping process. 

To give an idea of FaustLive’s potential, the 
following section presents its diversified fea¬ 
tures, showing the corresponding alterations in 
the structure of the applications. 

The starting point of FaustLive’s features is 
drag and drop. A Faust DSP can be opened 
in a new window or it can be dropped on a 
running Faust application. As a result, an 
intermediate state emerges in which the two 
applications coexist. The arriving application 
copies the established audio connections. Then, 
the output of the old application is cross-faded 
to the new one (Figure 5). At last, the dropped 
application durably replaces the previous one. 
With that system, a running application can 
be changed endlessly, without audio click. 

This mechanism also allows source edition. 
When the user chooses to edit its Faust code, 
it is opened in a text editor. And as his changes 
are saved, the application is updated using the 
crossfade mechanism (Figure 6). 


2 Q T is a framework for interface design 


JACK was primitively adopted as audio 
driver for it allows the user to connect its 
Faust applications between themselves. Other 
drivers have then been added, making this 
component of the structure as flexible as 
the others. So when Faust applications are 
running, FaustLive gives the possibility to 
dynamically switch the audio driver. FaustLive 
does not need to be stopped. The migration is 
made during execution and is applied to every 
Faust application running. JACK, NetJack, 
CoreAudio and PortAudio are the integrated 
drivers in FaustLive (Figure 7). 




Figure 7: Dynamic driver migration 


FaustLive expands its radius of action to ex¬ 
ternal interactions. A smartphone can open an 
OSC 3 interface, controlling the application re¬ 
motely (Figure 8). 

Likewise, a HTML interface is accessible 
through a Qr Code 4 . By scanning it with a 

3 OSC : Open Sound Control 

4 QR code (abbreviated from Quick Response Code) 
is the trademark for a type of matrix barcode (or two- 










































































































































Figure 8: OSC interface 


touchpad (for instance), the remote interface 
is opened in a browser. In both cases, the 
interface is duplicated and a synchronization 
between the local and remote interface is 
established. 

The HTML interface has an additional 
interest: it is set up to enable drag and drop. 
Therefore, the user controlling the remote 
interface can also change the behavior of the 
application by dropping his own DSP. It is sent 
to the local application where it replaces the 
running one, using the crossfade mechanism. 
Finally, the remote interface is updated (Figure 

9) . 

If many or/and heavy Faust applications 
are opened, local CPU load can be saturated. 
The migration of calculations to other machines 
can lighten this load. On account of dynamic 
compilation, the audio computation module 
can be relocated on another machine (Figure 

10) . The list of remote servers available is built 
dynamically so that it is simple to switch from 
local processing to remote processing. 

A user may wish to run his Faust appli¬ 
cation in an other environment (Max/MSP, 
SuperCollider, ...). For that matter, a link to 
Faust Web, a remote compilation web service, is 
integrated in FaustLive. The user only has to 
choose the platform and environment he wishes 
to target. In return, he will receive the binary 
of the requested application or plugin. 

When FaustLive is exited, the last configu¬ 
ration is saved and will be restored at its next 


dimensional barcode) 




Figure 9: Remote drop 



FROM LOCAL TO REMOTE PROCESSING 


Figure 10: Remote processing 


execution. A user may also save the state of 
the application at any moment. In a second 
phase, he will be able to reload his snapshot, 
by importing it in the current state or recalling 
it (Figure 11). 
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Figure 11: Reloading snapshot 


4 FaustLive - Technical View 

4.1 Basic FaustLive Features 

The first aim of FaustLive is to create a dynamic 
environment for Faust prototyping, by embed¬ 
ding libfaust. The resulting dynamic compila¬ 
tion chain (Figure 12) presents the advantage 
of speeding up the compilation process. Return¬ 
ing almost right away the executed application, 
this compiler is a stepping stone for dynamic 
behaviors. 


Faust code will lead to a recompilation. This 
particular aspect is central, for it simplifies 
the prototyping process: a user can modify his 
code at leisure and see/hear instantly the result. 


An important asset of FaustLive is the coex¬ 
istence of multiple Faust applications, in op¬ 
position with the QT-JACK architecture from 
Faust “static” distribution, where every Faust 
program has to be compiled separately to pro¬ 
duce its own application. Here, each application 
evolves with the actions it undergoes and has its 
own set of dynamic parameters (Figure 13). 
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Figure 12: Compilation chain in FaustLive 


Now that it is possible to dynamically 
compile Faust code, new prospects are rising. 
A user may drop his Faust code as a file, a 
string or a url, on a running application. As 
a result, the code is immediately given to the 
embedded compiler and the new application 
replaces the previous one. Since FaustLive is 
designed for dynamic uses, it is very important 
to ensure a continuity in the sound. For that 
matter, a crossfade is calculated between the 
two relaying Faust applications. 

Moreover, a Faust application is linked to 
its source, so that any modification in the 


Figure 13: FaustLive’s environment 


4.2 Audio Drivers 

FaustLive has integrated JACK, CoreAudio, 
Net Jack and Port Audio 5 . So that it’s possible 
to switch audio structures or modify its pa¬ 
rameters (such as buffer size or sample rate) 
during FaustLive’s execution. Every running 
audio client is stopped, then the applications 
are transferred in the new domain to finally be 
restarted. 

4.2.1 JACK 

JACK is a system for handling real-time, 
low latency audio (and MIDI). It runs on 
GNU/Linux, Solaris, FreeBSD, OS X and Win¬ 
dows. It can connect a number of different ap¬ 
plications to an audio device, as well as allowing 
them to share audio between themselves. 

5 JACK, CoreAudio and Net Jack are used on OSX, 
JACK and Net Jack on Linux, Port Audio, JACK and 
Net Jack on Windows. 


























































































































Therefore, an interesting constraint in using 
JACK is the matter of the connections. When 
connections have been established, the objec¬ 
tive is to maintain them even if the Faust 
application changes in a window. If the new 
application has more ports than the previous 
one, the user will have to make the connections 
himself. 

4.2.2 NetJack 

NetJack is a Realtime Audio Transport over 
a generic IP Network, fully integrated into 
JACK. NetJack synchronizes all clients to one 
soundcard, so there is no resampling or glitches 
in the whole network. The master imposes the 
sample rate and buffer size, in relation to its 
audio device. 

4.2.3 CoreAudio and PortAudio 

Because the protocol has to be strictly the same 
on the client and on the server’s side, JACK and 
NetJack have to be linked as a dynamic library. 
The problem it brings is that FaustLive’s in¬ 
stallation is linked to JACK’S installation. To 
avoid this inconvenience for beginner users, a 
CoreAudio 6 and PortAudio 7 versions have been 
developed. Included in the standard libraries or 
easily linked as a dll, they do not expand the 
user’s work. 

4.3 Control Interfaces 

To offer a modular application, FaustLive 
expands the choices of the user, concerning the 
control interface. 

4.3.1 OSC Interface 

OSC protocol is integrated to FaustLive to 
offer another type of interface and enable 
interoperability. Many audio environments 
and devices implement this protocol so that 
FaustLive will be able to communicate with 
them. The user can configure the port on 
which the protocol is started and then control 
the interface with, for instance, an OSC touch 
application. 


6 CoreAudio is the digital audio infrastructure of iOS 
and OS X. It provides a framework designed to handle 
audio needs in applications. 

7 PortAudio is a free, cross-platform, open-source, 
C/C++ audio I/O library. It is intended to promote 
the exchange of audio software between developers on 
different platforms. 


4.3.2 HTML Interface 

Faust HTML interface is also a component of 
FaustLive. Loaded on any browser, this inter¬ 
face controls the DSP’s parameters, through a 
HTTP connection. When it is built, a server 
is started, taking care of delivering the HTML 
page (Figure 14). A synchronization between 
the local and the remote interface is also in¬ 
sured. 

To ease the opening of the interface, a Qr 
Code is built from the HTTP address, thanks 
to libqrencode. Most smartphones and portable 
equipments have a QrCode decoder. By scan¬ 
ning the Qr Code, a browser gets connected to 
the interface page. 

4.3.3 Preferences 

The challenge FaustLive was confronted with 
is to provide an interface that gives as many 
liberties as possible to the user all the while 
being easy to apprehend. In that direction, 
OSC and HTTP ports are configurable in 
the window’s options. The window toolbar 
is collapsed, by default, so that a “basic” 
user won’t feel assailed by preferences (Figure 
13). Both protocols use 5510 as default port. 
When the TCP listening port number is busy, 
the system automatically looks for the next 
available port number. 



Full html page 


Figure 14: HTML interface with control and 
dropping services 

4.3.4 Remote Drag and Drop 

As the rest of Faust current distribution, 
the HTML interface has a “static” behavior. 








The intention, to copy FaustLive’s dynamic 
behavior, led to adding a dropping area to 
the HTML interface. This HTTP service is 
independent and specific to FaustLive. The 
server, started by FaustLive, is able to create 
a HTML page that encapsulates the remote in¬ 
terfaces. The resulting service of remote inter¬ 
face and DSP drop has the following address: 
http://IP:DroppingPort/InterfacePort (Figure 

14). 

The dropping port is set in the preferences 
and is common to all the Faust applications. 
The remote interface port is distinct for every 
Faust application and editable in the window’s 
options. 

The reaction to the drop follows FaustLive’s 
model. The DSP is first sent to FaustLive as a 
HTTP post request. The DSP is compiled and 
replaces the previous one, after the crossfade. 
At last, the remote interface is updated. 

4.4 Remote Processing 

To widen its benefits, FaustLive enables remote 
processing. The compilation and process 
calculation are redirected on a remote machine 
and local CPU load can be lightened. 

On a remote machine, an application starts 
a HTTP server, offering the remote compila¬ 
tion/processing service. This server is waiting 
for requests. 

On the client’s side (FaustLive), an API 
“proxy” makes it transparent to create a 
remote-dsp rather than a local llvm-dsp (c.f 
2.2). This API, libfaustremote , takes care of 
establishing the connection with the server. 

The first step (compilation) is carried out 
by the function createRemoteDSPFactory. The 
code is sent to the server, which compiles it 
and creates the “real” llvm-dsp-factory. The 
remote-dsp-factory returned to the user is an 
image of the “real” factory. Before sending the 
Faust code, a Faust to Faust compilation 
step is executed locally, to solve all the depen¬ 
dencies. This way, the expanded code sent to 
the server is self-contained. 

The remote-dsp-factory can then be instan¬ 
tiated to create remote-dsp instances, which 
may run in the audio/visual architecture cho¬ 
sen (here, FaustLive). 

To be able to locally create the interface, the 
server returns a json-encoded interface. This 


way, the function buildUserInterface can be 
recreated, giving the impression that a remote- 
dsp works as a local llvm-dsp. 

Moreover, the audio processing is redirected 
through a Net Jack connection. The audio data 
is sent to the remote machine which processes 
it and sends back its results. In addition to 
the standard audio flow, one midi port is used 
to transfer the controllers values (Figure 15). 
The benefit of this solution is to transmit 
synchronized audio and controllers in the same 
connection. Moreover, the audio samples can 
be encoded using the different possible audio 
data types : float, integer, and compressed 
audio (using the OPUS codec 8 ). 



Figure 15: Remote compilation 


libfaustremote uses libcurl to send http 
requests to the remote server, handled with 
libmicrohttpd. 

On FaustLive’s windows, the service of re¬ 
mote processing is simply interfaced. The Zero- 
Conf protocol is used to scan the remote ma¬ 
chines presenting the service. A list is then 
dynamically built with the available ones. By 
browsing in the list, the user can then switch 
from a machine to another or come back to lo¬ 
cal processing very easily. 

4.5 Faust Web 

In order to simplify the accessibility of the 
Faust compilation, this web service of remote 
compilation has been conceived. It receives a 
Faust DSP and returns a plugin or applica¬ 
tion in the chosen target architecture. As an 
outcome, the installation of Faust package and 
all additional SDKs on the user machine is not 
necessary anymore. Anyone can write a Faust 

8 http://www.opus-codec.org 

































application, send it to the server and receive a 
plugin. 

This service is accessible from a browser but 
requires several requests. Through FaustLive, 
the export is facilitated. A menu is dynami¬ 
cally built with the platforms and architectures 
available. And as the user makes his choice, 
his code is sent to the server. The first step is 
the syntax verification, returning a shal key, 
with which multiple requests can be made. 
The second step is the compilation, using 
the standard “static” chain and returning the 
chosen application to the user (Figure 16). 


FAUSTLIVE FAUSTWEB 



Figure 16: Steps of the compilation chain 
through Faust Web 


4.6 Session Management 

A concept of session is introduced to preserve 
the state of the application (parameters values, 
position on screen, audio connections, compila¬ 
tion options, ...) when the application is closed 
or when the user takes a snapshot, which saves 
his session in a .tar file. 

A FaustLive snapshot is self-contained. All 
the local resources needed (like Faust DSPs) 
are copied into the folder. Pointers to the re¬ 
sources are used as much as possible. But if 
a source file is erased or the snapshot is trans¬ 
ferred on another machine, copies ought to be 
employed. 


To decrease the compilation time, the out¬ 
put of Faust compiler, the optimized LLVM 
IR code, is saved. When the application is re¬ 
called, Faust compiler’s and LLVM IR to IR 
optimization steps are skipped. For very heavy 
programs, the gain can be noticeable (from a 
few seconds to almost instantaneous). 

5 Conclusion 

FaustLive brings together the convenience of a 
standalone interpreted language with the effi¬ 
ciency of a compiled language. 

FaustLive offers currently the shortest de¬ 
velopment cycle for Faust applications, allow¬ 
ing even to modify the code of an application 
while it is running. It integrates advanced re¬ 
mote computation and control features for real¬ 
time distributed audio applications. Moreover 
FaustLive provides, via its export functionality, 
a convenient front-end for Faust Web, the com¬ 
pilation web service of Faust. The project is 
open-source and available on Sourceforge [3]. It 
runs on Linux, OSX and Windows. 
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